Sessions and Information
A “session” can be viewed as the back and forth communication over a network between a pair of computing systems. Referring to FIG. 1, in the case of a client/server architecture, basic back and forth communication involves a client 101 sending a server 100 a “request” that the server 100 interprets into some action to be performed by the server 100. The server 100 then performs the action and if appropriate returns a “response” to the client 101 (e.g., a result of the action). Often, a session will involve multiple, perhaps many, requests and responses. A single session through one or more of its requests may invoke the use of different application software programs.
An aspect of session management is the use of session state information over the course of a session's end-to-end lifetime. Session state information is a record of the status and/or use of a session. For example, as part of a server's response process, the server may save in the session state information a time in the future at which the session is to be deemed “expired” if a next request is not received by the server for that session beforehand. Session state information may also include information used to “pick-up” a session from where it last “left-off” (such as the latest understood state of a client's web browser), and/or, data or other information sent to the user over the course of the session (such as one or more graphics or animation files whose content is presented to the client as part of the client's session experience)
Persistence
In the software arts, “persistence” is a term related to the saving of information. Generally, persisted information is saved in such a fashion such that, even if the entity that most recently used and saved the information suffers a crash, the information is not lost and can be retrieved at a later time despite the occurrence of the crash. For example, if a first virtual machine suffers a crash after using and saving information to persistent storage, a second virtual machine may, subsequent to the crash, gain access to and use the persistently saved information.
FIG. 2 provides a simple example of the concept of “persistence” as viewed from the perspective of a single computing system 200. Note that the computing system 200 of FIG. 2 includes DRAM based system memory 210 and a file system 220 (noting that a file system is typically implemented with one or more internal hard disk drives, external RAID system and/or internal or external tape drives). Traditionally, the system memory 210 is deemed “volatile” while the file system 220 is deemed “non-volatile”. A volatile storage medium is a storage medium that loses its stored data if it ceases to receive electrical power. A non volatile storage medium is a storage medium that is able to retain its stored data even if it ceases to receive electrical power.
Because a file system 220 is generally deemed non-volatile while a system memory 210 is deemed volatile, from the perspective of the data that is used by computing system and for those “crashes” of the computing system effected by a power outage, the file system 220 may be regarded as an acceptable form of persistent storage while the system memory 210 is not. Here, if the computing system saves a first item of data to the system memory 210 and a second item of data to the file system 220 and then subsequently crashes from a power outage, the second item of data can be recovered after the crash while the first item of data cannot. File systems can be internal or external (the later often being referred to as “file sharing” because more than one computing system may access an external file system).
Another form of acceptable persistence storage relative to computing system 200 is an external database 230. A database 230 is most often implemented with a computing system having “database software”. Database software is a form of application software that not only permits data to be stored and retrieved but also assists in the organization of the stored data (typically in a tabular form from the perspective of a user of the database software). Traditionally, database software have been designed to respond to commands written in a structure query language (SQL) or SQL-like format. Here, referring back to FIG. 2, if the computing system stores an item of data in the external database and then subsequently crashes, the item of data can still be accessed from the external database.
External databases are particularly useful where information is to be made accessible to more than one computing system. For example, if the external database 230 is designed to hold the HTML file for a popular web page, and if the depicted computing system 200 is just one of many other computing systems (not shown in FIG. 2) that are configured to engage in communicative sessions with various clients, each of these computing systems can easily engage is sessions utilizing the popular web page simply by being communicatively coupled to the database. External file systems also exist.
Persistence of Session State Information
FIG. 3 shows that session management 301 and persistence 302 functions may overlap. Notably, the persistence of a session's session state information permits the possibility of a session to be successfully continued even if an entity that was handling the session crashes. For example, if a first virtual machine assigned to handle a session crashes after the virtual machine both responds to the session's most recent client request and persists the corresponding state information, upon the reception of the next client request for the session, a second virtual machine may seamlessly handle the new request (from the perspective of the client) by accessing the persisted session state information. That is, the second virtual machine is able to continue the session “mid-stream” because the session's state information was persisted.